my collection of random things and thoughts

Daily Task Structure with eInk Tablet and nixOS (Part 1)

"'Reyno de Napoles anotomizado de la pluma del don Francesco Cassiano de Silva' (1700) - ink drawing and water-colour - Detail - Exhibition at National Library of Naples" by Carlo Raso is marked with Public Domain

A while ago I started using an eInk tablet for taking notes and organizing, replacing my traditional physical notebook approach.

The Tablet

The tablet in question is the Boox Note Air4 C. I like it, but I only have an iPad Pro as comparison. Originally I intended to buy the Boox Note Max, but it was out of stock for a while at the time and I did not want to wait. In hindsight I regret this decision, because a bigger screen would have been beneficial. There many other eInk tablet producers out there, therefore I encourage you to dive into the topic - to name a few are SuperNote and re:Markable, which were among by top 3 choices.

The Struggle

This worked very well using the integrated app. I set up a structure for private and work related and all sorts of subcategories, e.g., making my own "visualizations" of algorithms to better understand them. Besides the structure, I wanted to backup/sync my notes. Luckily this was a built in feature as is not necessarily the case with all eInk tablets or to be precise, is severely limited, e.g., the SuperNote has no "open" sync option. What do I mean by open: Anything you can self-host and/or is open-source, e.g., WebDAV. Which in my opinion is very very important. So I set out to connect my notes to my WebDAV based cloud (Nextcloud), which worked rather flawless.

But after a few months the struggle(s) began. Export started to become slow and or flaky. Turns out the export is not necessarily smart and renders the "raw" file to a PDF and then uploads ginormous PDFs via WebDAV, which directly conflicts with the auto-sleep feature of the tablet, often cutting larger uploads. The software allows exporting the raw files, but not raw+pdf which is sad. I intend to use the raw files export in the future and write my own sync backend to ideally have delta based updates and rendering of the raw files into less bloated PDFs. The solution to this issue was rather simple for now: Create notes per week per topic, e.g., Prefix_W14_Title. This is relative low overhead and has the most impact on file sizes and also in-note performance as I have the feeling "big" notes are sluggish. When does a note "feel" big you might ask? Well anything after 10-20 pages feels not great in my opinion, which is a bit sad and I do not understand the technical underpinnings that cause this to happen, my naive assumption is that it's a big file with suboptimal access structure and suboptimal access patterns.

On the non-technical side I was noticing that I lost focus between today and yesterday inside the same note, because information was on a previous page (bigger screen would have enabled me to have 2 days on the same page - maybe?) and or forgetting about private or other related notes, because they were in a completely separate subfolder. This would not be a problem in the physical world for me, because these things were actually different physical objects. Ending a day noticing that I sometimes missed updating/taking notes on a certain topic or marking something as done or even completing it was increasingly frustrating.

I quickly came up with an idea to try and tackle this issue of "visibility".

The Solution: A Tale of Learning and Possibly Over-Engineering

Since the main issue was having the most important and recent notes always present without one topic hiding the other the solution was simple: Have a secondary device, in direct view, always display the most important notes. Using an eInk tablet of an iPad because of my new found passion for eInk displays meant it had to be an eInk device. But that "dream", quickly died. A big enough eInk display is just too expensive. I would have rather bought a 4090 RTX or god forbid 5090 RTX and it would have felt like a more reasonable expense. So I checked for low power "regular" displays. And you can easily find things around 10W from iiyama. So I went and bought a 27" screen.

Obviously a screen is not enough, we need a device to get the relevant documents and display them. Since I wanted to spent as little money as possible I took my Raspberry Pi 4, which I had been abusing for USB OTG experiments, that ended in me just buying OTG capable Espressif32 Nano Arduinos and never looked back. At that time I was already starting to flirt with nixOS. I am still a total nixOS noob, but thought, let's just flash nixOS onto it and ride with it. Hence my previous post [nixOS on a Pi from the SSD](/nixOS on a Pi from the SSD.html).

Once I had tamed the beast I was ready to glue together my software setup that would enable me to get the files for display. I did a cursory search for WebDAV libs in Rust, found nothing convincing and thought WebDAV being such a well established standard there must be good cli support out there. Thinking this would be the pragmatic and fastest approach I started building a nushell based workflow, which extracted meta data from PDFs, and cut out the last two pages into another output PDF etc. This part worked fine. Now I went over to the file sync part - which I assumed would be the most straightforward part. I was very wrong. I went down a rabbit hole trying to use the Cyber/Mountainduck CLI which is written in Java. The CLI supposedly supports Nextcloud out of the box, but I could not get it working so I used the regular WebDAV support of the CLI. To my surprise, they do not publish binaries (correct me if I am wrong). They publish a wide variety of packages, brew, rpm/deb, msi/exe, docker image, but god forbid a binary. Finding that out took some time. So my idea to have the setup in one nix flake where I swallowed the bitter pill of fetching the blob was not an option. I then decided to see if I can create a flake.nix for the source repo, but quickly ran into maven issues, which I decided are not worth my time.

So I tried davix which comes already as nixpkg. davix somehow just did not care and did not work with Nextcloud. I was getting 401 or other errors all the time and the debug option was immediately spewing out the most verbose curl output including the TLS related information which made it very bloated. I did not see the point in trying to understand why the correct URL which worked for every other CLI I tried and setting the username and password options on the CLI tool would cause trouble. This might seem entitled but, this is just not a good tool.

Remember when I said in an earlier paragraph that I thought the CLI/script approach would be the most pragmatic? I created a fresh cargo project with flake.nix and fenix, used the least old Rust library for WebDAV that I had found. Configured the client. Tried the list files command. It worked. This took me not even 5 minutes. I was rather pissed at myself for spending the other day fighting with various solutions.